我們在實作一個系統的時候，總是會有一些預期的結果，而這些預期的結果，我們稱之為斷言（Assertion）。但我們沒有要來說程式怎麼寫斷言，而是要來說明，我們要怎麼確認我們做的方向是不是正確的。

確認可以有幾個層次：

1. 和用戶方的確認
2. 和系統方的確認
3. 和未來規劃的確認
4. 和跨領域的確認

和用戶方的確認

用戶的確認，就是我們要確認我們的系統是不是符合用戶的需求。這個確認的方式，就是要和用戶方溝通，並且確認他們的需求是不是被滿足了。

建議在開發的過程中，設定週期性的demo，讓用戶方可以看到我們的進度，並且給予回饋。這樣可以讓我們在開發的過程中，就可以確認我們的方向是不是正確的。

這個確認是和需求方的確認。

和系統方的確認

在開發的過程中，完成一個段落之後，我們可以透過階段性的測試，並回顧我們的系統設計和實作，這個確認是和工程師方的確認。

這個確認週期可以是一個迭代，也可以是一個階段，只要和團隊的工程師默契一致就好，形式並不是那麼重要。

和未來規劃的確認

在開發的過程中，我們會發現一些問題，這些問題可能是我們的系統設計不夠好，也可能是我們的系統設計不夠完整，也可能是我們的系統設計不夠完善。

這個時候必須要即時回饋給「主要設計者」和「主導者」

當然這個回饋不僅僅是問題，也可以是我們的系統設計的改善方向，還可以是已經發現的問題的解決方案。

和跨領域的確認

因為每個專案的規模不同，所以跨領域的確認，可能是和其他團隊的確認，也可能是和其他專案的確認。

例如某個專案需要一個「偵測事件」的機制，這個機制可能是和其他專案的機制相同，這個時候我們就可以和其他專案的團隊溝通，看看他們的機制是怎麼做的，並且和他們確認我們的機制是不是和他們的機制相同。

這個確認是和其他團隊的確認。

總結

1. 和用戶方的確認，確認產出的東西是不是符合用戶的需求
2. 和系統方的確認，確認系統走向是不是正確的
3. 和未來規劃的確認，確認整體規劃是不是符合主導者的規劃
4. 和跨領域的確認，確認我們的系統是不是和其他團隊的系統相同
5. 以上的確認，都只在乎方向，不在乎形式，建議週期性的確認，而不是等到最後才確認